Test case

Use the following integration cases to review your integration qualities. To create a good user experience, ensure that the common payment scenarios are properly handled.

Notes:

• Use iValidate ONLY when your product is ready to go live.
• To simulate real payment scenarios, all test cases must be started by using PAYMENT TERMINALS, rather than by manually calling APIs.
• After your product goes live, PayBy will analyze your transaction status and identify the hidden integration problems or problems caused by code changes.

Case-001 Payment with password authentication triggered

When a single payment greater than or equals to a certain amount (usually is AED 500),PayBy users might be prompted to enter the password to complete the payment. This test case is to check whether your system can properly handle this scenario.

Acceptance rules:

- Both [Partner-Id] and [merchantOrderNo] are required in the request.

- The payment amount is greater than or equals to AED 500.

- Payment interface responds [status=CREATED].

- Send at least one query request.

- The query request frequency is 2-6 seconds.

- The last query request found that the transaction was successful.

Case-002 Payment expires

Sometimes PayBy users might choose not to continue when they are prompted to enter the password to complete the payment, and the payment finally expires. This test case is to check whether your system can properly handle this scenario.

Acceptance rules:

- Both [Partner-Id] and [merchantOrderNo] are required in the request.

- Payment interface responds [status=CREATED].

- Send at least one query request.

- The query request frequency is 2-6s.

- Send [cancelOrder] request 20 to 120 seconds after the transaction is initiated.

Case-003 Payment failed with SYSTEM_ERROR returned

SYSTEM_ERROR is returned when a payment request goes wrong. This test case is to check whether the system can handle the SYSTEM_ERROR according to the best practices recommended by PayBy.

Acceptance rules:

- Both [Partner-Id] and [merchantOrderNo] are required in the request.

- Payment interface responds SYSTEM_ERROR.

- Send at least one query request.

- The query request frequency is 2-6 seconds.

- Send [cancelOrder] request 20 to 120 seconds after the transaction is initiated.

Case-004 Payment timeouts

A payment request might timeout because of poor network or PayBy system error. This test case is to check whether the system can handle timeout errors according to the best practices recommended by PayBy.

Acceptance rules:

- Both [Partner-Id] and [merchantOrderNo] are required in the request.

- Payment interface responds SYSTEM_ERROR.

- Send at least one query request.

- The query request frequency is 2-6 seconds.

- Send [cancelOrder] request 20 to 120 seconds after the transaction is initiated.

Case-005 Cancel succeeds after multiple attempts

When a cancel fails, the merchant must keep calling CANCEL until the cancel succeeds. This test case simulates the scenario where cancel finally succeeds after multiple attempts.

Acceptance rules:

- Both [Partner-Id] and [merchantOrderNo] are required in the request.

- Send at least one query request.

- The query request frequency is 2-6 seconds.

- Send [cancelOrder] request 20 to 120 seconds after the transaction is initiated.

- The CANCEL request frequency is 3-10 seconds.

- At least three CANCEL requests are required, and only the last request returns SUCCESS.

Case-006 Cancel fails after multiple attempts

When a cancel fails, the merchant must keep calling CANCEL until at least more than 3 FAILs are returned, or until cancel requests keep failing for more than 10 seconds. If cancel still fails, the responsible person must be notified of the problem. In production environment, technical support must be contacted to confirm the transaction status and handle the problem.

Acceptance rules:

- Both [Partner-Id] and [merchantOrderNo] are required in the request.

- Send at least one query request.

- The query request frequency is 2-6 seconds.

- Send [cancelOrder] request 20 to 120 seconds after the transaction is initiated.

- The CANCEL request frequency is 3-10 seconds.

- CANCEL requests must be made at least 3 times, All requests returns failed.

Case-007 Query succeeds after multiple attempts

When a query fails, the merchant must keep calling QUERY until the query succeeds. This test case simulates the scenario where cancel finally succeeds after multiple attempts.

Acceptance rules:

- Both [Partner-Id] and [merchantOrderNo] are required in the request.

- Send at least three query requests.

- The query request frequency is 2-6 seconds.

Case-008 Query fails after multiple attempts

When a query fails, the merchant must keep calling QUERY until at least more than 3 FAILs are returned, or until requests keep failing for more than 10 seconds. If cancel still fails, the responsible person must be notified of the problem. In production environment, technical support must be contacted to confirm the transaction status and handle the problem.

Acceptance rules:

- Both [Partner-Id] and [merchantOrderNo] are required in the request.

- Send at least three query requests.

- The query request frequency is 2-6 seconds.

Case-009 Return a [SUCCESS] response to PayBy after received the notification

After the payment is successful, PayBy will send the payment result of the order and the user information to the merchant in the form of a data stream. The merchant needs to receive and process it, and return a [SUCCESS] response to PayBy.This test case is to check whether the system can handle the notification.

Acceptance rules:

- Receive and process the notification.

- [SUCCESS] is required in the return response.